@Tyriar Yupp most likely will be able to have a look at it in the afternoon. No clue yet if I manage to go deeper into details, ~20k loc is still a frightening number for a single quick review. I also have no doubt about code quality of the pulled in source, thus will skip most inner parts and mostly stick to a better conceptual comprehension.

One thing upfront - what you write about getting code fixes carried over with the help of additional scripts sounds a bit bothersome to me from a maintenance perspective. Do you see a chance, that your team would bundle&release the custom scrollbar functionality as a standalone package in the future? (Well idk if thats feasible or worth the trouble at all, have not yet looked at the code...)

One thing upfront - what you write about getting code fixes carried over with the help of additional scripts sounds a bit bothersome to me from a maintenance perspective.

I will probably be the one doing this and I doubt it will happen very often, like so infrequently that it definitely isn't worth trying to ship some lib. For example we will likely want to move over to the event and lifecycle code since it's more robust than ours and duplicates its functionality, and I think since those files are already present they won't need to bring in any changes.

Prelude to the feasibility of GPU rendering in code editor. 😃

Here's the output, there's a pretty significant increase for the main xterm.js package but I think we should accept it still because:

• This will become the legacy package and maybe soon be replaced by a more efficient esbuild-based one.
• We will be able to remove parts of xterm.js in favor of base/ parts like events.ts and lifecycle.ts.
• For VS Code specifically the terminal startup is also deferred shortly to ensure we don't block the time to get an editor up and running so the impact there should be minimal.

All the addons are the same as expected so nothing leaked in there.

.js output (webpack) - measured by looking at Windows Explorer (seems to be larger? kB vs KiB?):

.mjs output (esbuild) - measured by esbuild output:

Planning on merging this soon today. I want to look briefly at the ctrl+c/smooth scroll issue that's been driving me crazy for months.

Fixed microsoft/vscode#211199 finally! It was very difficult with the old viewport because of the mess of circular dependencies that was the scroll events

Maybe this will be a good opportunity to do a v6. While no big breaking changes it does:

• Significantly change how the viewport works, so any custom styling of elements will break an embedder (like vscode)
• fastScrollModifier now does nothing

@tisilent good to know 👍

@Tyriar Yay thx for getting this & the ESM stuff done! 🥳

While the impact on bundle size is quite steep, I couldn't care less, since we get some solid and well tested stuff in return...

Edit: Yes, I second the idea to do a new major release at this point. Even though the API did not change substantially, the changes overall are still quite a lot, and well - ESM alone would qualify for that from an outer perspective.